-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing Java field access #1862
base: main
Are you sure you want to change the base?
Fixing Java field access #1862
Conversation
Blocked by #1586 |
c781e33
to
faaa036
Compare
4c7279c
to
952f56c
Compare
952f56c
to
5f75416
Compare
5f75416
to
c7f72a6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fail to understand most of the changes since the old code is hard to understand and the new code requires in-depth knowledge and understanding of the java parser and frontend which I do not have. However, I have some nits which should already be resolved and may support subsequent more detailed reviews.
@@ -209,7 +209,7 @@ open class SymbolResolver(ctx: TranslationContext) : ComponentPass(ctx) { | |||
// Preparation for a future without legacy call resolving. Taking the first candidate is not | |||
// ideal since we are running into an issue with function pointers here (see workaround | |||
// below). | |||
var wouldResolveTo = ref.candidates.singleOrNull() | |||
var wouldResolveTo = ref.candidates.firstOrNull() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change does no longer account for ambiguities. The old code with singleOrNull()
prefers not to resolve anything if it's not sure about the candidate. I think this was also intended, wasn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was semi-intended. I am ok with the old behavior, but we should at least
- have a warning if we do not resolve it
- forward the decision to the
Language
. In Java it is possible to have an ambiguity here if you statically import a field and a function and both can have the same name and end up in candidates. I need to deal with that here
val fieldRef = findByUniquePredicate(refs) { "field" == it.code } | ||
val getSuperField = findByUniqueName(methods, "getSuperField") | ||
refs = getSuperField.allChildren<MemberExpression>() | ||
val superFieldRef = findByUniquePredicate(refs) { "super.field" == it.code } | ||
assertTrue(fieldRef.base is Reference) | ||
assertRefersTo(fieldRef.base, getField.receiver) | ||
// See https://github.com/Fraunhofer-AISEC/cpg/issues/1863. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how this relates to the case of java.
// See https://github.com/Fraunhofer-AISEC/cpg/issues/1863. | ||
// We only have a regular call expression here, if we do not resolve anything else in the | ||
// frontend | ||
/*assertTrue(fieldRef.base is Reference) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commented out code. -> Remove or fix. What do we expect?
@@ -889,3 +658,21 @@ class ExpressionHandler(lang: JavaLanguageFrontend) : | |||
} | |||
} | |||
} | |||
|
|||
fun ResolvedFieldDeclaration.toFieldAccessExpr(expr: NameExpr): FieldAccessExpr { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation missing
// } | ||
val name = this.parseName(nameExpr.nameAsString) | ||
return try { | ||
// Try to resolve it. We will remove this in a future where we do not really in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the TODO
of this method resolved? If so, please delete it.
Also, please document the method according to the new standards: #1683 (comment)
This sentence is broken
?: newProblemExpression("Could not parse base") | ||
} | ||
var fieldType: Type? | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please document the method according to the new standards: #1683 (comment)
|
||
@DependsOn(TypeResolver::class) | ||
@ExecuteBefore(SymbolResolver::class) | ||
class JavaExtraPass(ctx: TranslationContext) : TranslationUnitPass(ctx) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Documentation missing for this whole file
c7f72a6
to
592b8ce
Compare
Agreed. I will extract the remaining changes that are not Java-specific to extra PRs (#1908 and #1909) |
592b8ce
to
d4cd2a8
Compare
…t of candidates This adds a new function `Language.bestViableReferenceCandidate` which takes the old implementation as a default behaviour.
…tion` This introduces a new extension function `ImportDeclaration.updateImportedSymbols`. The idea behind that is that we might need to update the `importedSymbols` of an import declaration, if the symbols that "live" in the associated namespace change. This is mainly the case once we infer records out of known `Type` nodes. Therefore, the type resolver will update all the imported symbols before executing all the remaining passes. This way, the remainder of the passes can access imported symbols that were inferred.
d4cd2a8
to
0494bdb
Compare
This PR consists of a major overhaul of Java reference and member expression parsing. It removes a LOT of old weird legacy code that was full of weird things.
It also introduces a new Java-specific pass, that takes care of deciding when a member access is actually static or not. This might be something that we could decide to adapt for other/all languages (maybe also tied to the discussion in #1863).
It also contains some adjustments to the import system, more specifically when the
importedSymbols
field is populated. This might have implications for other languages and if wanted I can extract this into a separate PR.